---
description: 从技术角度出发，围绕战略设计所定义的领域模型进行技术实现，并完成软件的开发以及落地。
---

战略设计其实是一种用高层次的视野审视软件系统的方式，不会去关注具体实施的技术，包括通用语言，限界上下文，定义领域，子域。其实都在表达一个信息。我是运筹帷幄的。主导者必须对业务非常熟练。
## 领域

<RedSpan>一个领域本质上可以理解为就是一个问题域，只要是同一个领域，那问题就相同。所以，只要我们确定了系统所属的领域，那这个系统的核心业务，即要解决的关键问题、文件的范围边界就基本确定了。</RedSpan>

领域其实就是我们的范围，而范围实际上就是我们的边界，要做多少、做到什么程度、最低多少、最多多少。而范围定义下来之后，根据这个范围去计算要做的事情，这就是领域驱动设计。

:::tip
比如你现在要去做一个电商网站，那么你的进货，优惠规则，物流仓储，销售报表，这些直接跟你的业
务相关的东西都归属于领域，而所谓的领域驱动设计就是你需要预先把领域中所涉及到的数据，流程以
及业务规则搞清楚，然后再通过面向对象的方式为他去建立一个模型，这个模型就叫做领域模型。我们
再去选择合适的技术去对他进行实现。
:::
## 子域

建立完一个大的领域模型之后，由于整个模型太过于复杂，业务太过于分散，这时候就需要做拆分了。

比如电商系统很复杂，那么单独将它拆分成一个个的模块，订单、商品、库存等等。每个模块还能更细分，比如库存，分为本地库、异地库、三方管理库。这一个个小的模块，在领域驱动设计中就叫做子域。

这个时候，我们就可以一个个的去研究子域，当所有的子域都搞定之后，整个领域就都搞定了。<RedSpan>子域集合就是领域</RedSpan>。

这里虽然领域有点像微服务了，但是本质上微服务架构与领域驱动模型没有任何的关系。一个是思想、一个是架构风格。但是它们的目的都是一致的，都是希望能够将复杂的问题简单化。
<img src="https://wkq-img.oss-cn-chengdu.aliyuncs.com/20241214132934.png"/>

子域划分之后，由于不同子域的重要性以及功能属性完全不一样，所以又会将子域分为核心域、通用域和支撑域。

:::tip 为什么要对子域做单独的定义？
实际建设项目的时候，会有很多限制，比如预算，比如人员，如果平均分配，就会导致其中一些子域关注度不够。核心业务可能因为得不到足够的资源，导致项目失败。
所以，对应不同的子域应该采取不同的态度。
:::

> 比如淘宝跟京东。一个是C2C，一个是B2C。那么，显而易见的，C2C更加注重于服务，当然，这是对于买卖双方的服务。所以，你们会发现，淘宝所有的一切，都是为了保证卖家能够好好的卖出去货，买家能够把货收到。那么这样一单完成，钱到手。所以，我们还会对于商品进行展示，甚至直播展示，所以会有淘直播。所以这种模式核心在交易保证。
>而B2C呢，其实卖的是口碑，如果说C2C你需要直接保证交易，而B2C实际上会更加关注产品的质量，为什么这么说呢？因为我们的B2C实际上如果你产品质量不好，那么我就会直接找到你的B方，也就是商家端。所以他的生命线实际上是质量。包括同学们聊起京东，肯定第一反应是质量。这已经做为了产品属性标签。
> 可能有同学会说，淘宝就不用做质量了吗？或者说京东就不做交易保证吗？所以这就是我们的兼顾，我们的业务力量需要放在刀刃上，并不是说其他的地方我们不会兼顾。
> 这个时候可能有些同学会有一些问题，老师，京东跟苏宁是不是同一种商业模式啊，我去进行设计的时候能不能进行同类分析啊。
> 包括我们去进行子域划分的时候是不是可以Copy。
> 这里我告诉大家，肯定是不行的。苏宁实际上强调的是线下选货，线上卖货，他们的核心在于线下。是由典型的线下往线上走，这种方式其实看重的是线下的服务，包括他们核心的源头在于你线下要有足够的流量。你才能慢慢打通线上。

由于商业模式的不同，侧重点不一样。所以我们去进行软件设计的时候方式也会不一样。如果是中小公司的架构，跟不懂技术的老板应该聊的是这些东西，而不是具体的技术栈。
### 核心子域

核心域是整个业务系统的核心，所有的业务都要围绕着核心业务域展开。那么如何明确核心域呢？

比如我们的淘宝，按照淘宝的模式，那么在交易保证的情况下，交易双方的属性必定就是我们的核心，
比如返利，比如商户系统。

而京东则不一样，在京东自营模块而言，他们更加注重质量，这里的产品质量保证实际上不仅仅是产品
本身，产品运输过程中也会导致质量问题。包括采购系统，包括仓储，物流，供应链才是他们的核心。 


通常明确核心的方式是 <RedSpan>精炼业务域</RedSpan>。精炼是一个持续的过程，具体来说有以下几种方式；
* 领域愿景说明： 项目最初立项的目的是什么，目标是什么。为什么要做这个项目。
* 突出核心：精炼文档，标明核心，形成核心的领域模型。
* 内聚机制：项目越来越大的时候，要修改的可能会越来越多，这个时候你的代码可能会在原本的代码上增加很多，那么就有可能导致你原本的代码非常复杂。所以要将内聚的核心抽离出来。
* 分离的核心： 将核心域中的非核心元素（模型）分离出去；将非核心域中的核心元素（模块）移动到核心域中。
* 抽象核心：当不同模块的子领域之间有大量交互时,要么需要在模块之间创建很多引用(在很大程度上抵消了划分模块的价值),要么就必须间接的实现这些交互,而后者会使模型变得晦涩难懂.因此,把模型中最基本的概念识别出来,并分离到不同的类,抽象类或接口中.设计这个抽象模型,使之能够表达出重要组件之间的大部分交互.把这个完整的抽象模型放到它自己的模块中,而专用的详细的实现类则留在由子领域定义的模块中.

核心域的范围并不一定是一次就能确认的，可能需要迭代很多次，每一次都有可能扩大或缩小。
### 通用子域
通用子域是整个领域都能用到的子域，比如认证、 权限等等相关的模块。只需要能解决问题就行。

### 支撑子域
支撑域实际上就是不包含核心竞争力的功能，也不包含通用的功能，但是又是必须的支撑。比如限时拼团功能，没有他电商网站能够正常运行吗，可以，但是为了配合活动，他能够辅助我们成单。但是在某些专门的拼团电商中他又是必须的核心。所以我们必须根据当前的情况来进行分析。


<RedSpan>领域驱动的核心思想就是将问题慢慢细化，同时找出最核心的问题点，倾斜资源保证核心资源不出问题，同时也可以通过领域的细分，去慢慢的缩小我们的子域所要解决的问题，并且构建合适的领域模型，到这一步为止，其实他跟我们的微服务都是有异曲同工之秒的。</RedSpan>

## 通用语言
随着你们公司项目的推进，这个时候你们的技术专家，架构师，后端，前端，测试都会参与你们的整个项目。相信大家经常会遇到这样一个问题，做为后端开发，你觉得跟产品经理聊天在对牛弹琴，而测试觉得你们开发的代码全是BUG，项目经理觉得你每天没做事，觉得你工期还应该更紧一些。导致这样的问题出现的根本原因是什么呢？

由于整个项目角色太多，每个角色都有自己的专业性，并且都有一套自己评估项目的方式。所以不同专业的内容碰撞起来就会导致信息的失真。那么这个时候怎么办呢？必须要有一个东西能够让我们的团队人员交流起来有一个标准。并且他还需要能够正确的，简单的，清晰的表达业务。让我们的技术专家，业务人员，产品，测试，架构都能够达成共识，并且协同合作。这个叫做通用语言。


## 限界上下文
在战略设计上，提出了限界上下文的概念，来确定领域的边界以及该上下文环境。

限界上下文用来封装通用语言和领域对象，提供上下文环境，保证在领域内的一些属于、业务相关对象等（通用语言）有一个确切的含义，没有二义性。这个边界定义了模型的适用范围。

限界上下文可以拆解为两个词，限界和上下文。限界就是领域的边界，也就是范围，而上下文是语义环境。通过领域的限界上下文，就可以在统一的领域边界内用统一的语言进行交流。






